Tear Down This Wall is a physics-based rapid-prototyping experiment using Unity. The game was developed over a 48-hour period, which involved about 15 hours total development time. The object of the game is to tear down a brick wall by firing cannonballs at it. You earn medals for clearing each stage with as few shots as possible, with later stages introducing a few surprises.

Soundtrack

Tear It Down

Building A Prototype

What follows is a development retrospective for the Tear Down This Wall rapid prototyping project, granting insight into the process, the feedback, and the decisions made along the way to bring the game to where it is today.

Build 1

Well this isn't very attractive... :P

This was the very first build I published. It got the basic, initial idea of the game across: knock the green blocks off the stage, do not knock any red blocks off the stage. You scored points for every gray block you cleared, but if you got greedy, you ran the risk of clearing a red and failing the stage. This risk-reward setup was kind of interesting, though I started to suspect a problem: with all the blocks in contact, the physics-driven wall collapse wasn't predictable enough to reliably avoid "accidents". I suspected this might lead to player frustration down the road.

Build 2

Adding a second stage and the framework for a stage-select menu...

In this build I added a second stage, to see how much variety I could wring out of this gameplay mechanic. I also started playing around with casting some light onto the scene; obviously with terrible results. :P

My concern from the last build, about the red blocks being more annoying than fun, quickly became very real at this point. It presented a significant obstacle to stage design, since it was virtually impossible to put a green block below a red block and still be able to complete the stage, which greatly limited the kinds of block configurations I could set up.

Build 3

And now... madness!

At this point the problem of stage variety, induced by the limiting mechanic of red blocks, was clearly a problem. I tried adding some other block types to inject additional axes of variation into the stage design process. Here I've introduced blue blocks, which simply disappear when hit directly by your projectile, and black blocks, which "explode" when hit, applying a force to other blocks nearby.

The blue blocks didn't give me a lot here, but the black blocks were somewhat promising, in that it was gratifying to watch all the other stuff around them explode away (even though the impulse was quite weak in this build). However, the volatility of a black block actually exacerbated the "red block accidents" problem.

I also tried setting up a crude "machine" with a green block orbiting a black block at the top of the stage, attached by a constraint. It was impossible to clear this green block by hitting it directly; instead, you had to hit the black block, which would explode the constraint and send the green block flying. It seemed like this mechanic might add an interesting element of timing to the game.

Build 4

Prettifying, but to what end?

There were really only two major changes in this build. The first is obvious: I prettified the graphics. This did precisely nothing to solve the "red block accidents" problem, but I suppose it got my mind off it for a while, which sometimes is creatively useful. ;)

I also introduced the concept of different-sized projectiles. In this build you could choose to fire a small, medium, or large projectile. They differed in size, shape, and physics properties. The small one fired like a bullet, and was fairly good at clearing bricks out of the wall without disturbing the stuff above the impact site too much. Unfortunately, its fast speed and tiny size introduced some physics bugginess where it would sometimes fail to register collisions. The large projectile was wider than it was tall, and very "lobby", so you had to aim high. It felt very heavy, which was kind of neat, but it was very hard to use effectively.

Ultimately, none of these changes really solved the problem. With the self-imposed 48-hour deadline drawing near, I finally resigned to go back to the drawing board: the "red block" mechanic just wasn't working.

Build 5 (Final Publish)

Success at last!

After some reflection, I realized that the core idea of the game was, as its title suggested, to tear down a wall. Not to selectively tear down a few things, while trying really hard not to tear down other things. No, the right approach here was to fully embrace the game's fundamentally destructive theme. Tear that shit down!

But if it was all about clearing the stage, what would be the limiting mechanic to introduce skill, to make it an actual game instead of just a quickly-forgotten toy? I experimented with limiting the number of shots you could take, so you really had to make each one count, and that exposed a nice bit of gameplay where, like a demolition engineer, you started analyzing the structure for its most vulnerable points. This was exactly the right mindset to be in. Finally, a break!

Ultimately, I decided not to apply a hard shot limit, but instead to award progressive medals for better performances. This allowed players to just enjoy the gratification of firing a hail of cannonballs at a physically-reactive wall without constraints, if they so desired, and also created a progressive challenge system: "You did well, but you could still do better." Easy to learn, a little less easy to master.

The explosive blocks stuck around, and got a nice sound effect and screen flash and a stronger impulse, which really sold the gratifying aspect of tearing the wall apart. I also discovered that by making some blocks kinematic -- meaning they aren't affected by physics forces, and thus are immovable -- I could, with varying configurations, make different walls more or less stable. These two mechanics, hand-in-hand, led to a sudden rush of stage design ideas; the final build features seven unique stages.